|
|
|
|
|
|
|
Figure 18.1.
The Options dialog box. |
|
|
|
|
|
|
|
|
The Error-Processing and Exception-Handling Subsystem Object Model |
|
|
|
|
|
|
|
|
The Error-Processing and Exception-Handling Subsystem doesn't easily fit into any application tier because it is an integral part of all tiers. However, the exception portion generally falls under the business tier for business applications, or the domain tier as it is known in nonbusiness applications. |
|
|
|
|
|
|
|
|
Figure 18.2 shows the typical interaction between an object, SomeObject, and the ErrorHandler object. If SomeObject invokes a method, but does not comply with the intrinsic contract between it and ErrorHandler, the latter will raise an error to let SomeObject deal with it. In Figure 18.3, ErrorHandler deals directly with the user so that the user can fix the problem. Figure 18.4 goes a step further. It shows the sequence of events that happens when a foreign object is used by your component, LocalComponent, on behalf of an object, SomeObject, in a client application. Because the LocalComponent used a reference to ForeignObject, it had the responsibility of trapping, interpreting, and raising foreign-originated errors on behalf of SomeObject. |
|
|
|
|
|
|
|
|
Modeling the Subsystem Class Hierarchy Model |
|
|
|
|
|
|
|
|
Typically, only one class is involved in simple error- and exception-handling subsystems. However, in a distributed or Web-based architecture, there can be many objects that enforce errors and exceptions. For instance, you might have a business rule engine component that handles all business rule violations on a server machine that is separate from the machine that hosts a component that handles date-formatting errors. With a Web-based system, you may have an object residing on an HTML page that handles local errors while another on the server handles Active Server Pages' problems. |
|
|
|
|
|
